While working with Fynd, I've been given multiple opportunities to create product workflows pertaining to the Retail ERP domain including the likes of Order Management Systems, SCM Rule Engines, Checkout Pages, Payment Modules etc.

I often while working on ideas used to assist ideas with detailed wireframes to convey the vision to concerned parties. It benefits to understand workflows, and also helps as a foundation to add on to later.

While most people carry wire-framing as a staged activity between 2 steps, I see it as an extension to the thought process similar to how we write points, show graphs, highlight KPI's etc.

Nevertheless, a well drafted wireframe doesn't mean or contribute to the fact that you made the right thing! It's merely an extension to your though, and a way to better communicate your ideology to any second or third-party person.

For instance, here's an example of a decently drafted wireframe that didn't make the cut. Look further to understand why :

Why did this not make the cut? It looks structured, but is it really required as a business decision?

This "Add Payments Page" for the client unfortunately did not make the cut to the final Flashpay module since majority of customers do not require to link payments and prefer usage of convenient one-time payment modes such as Credit Card / Debit Cards, or seamless flows such as PayTM, Google Pay, UPI etc.

Companies like Swiggy, Uber, Dunzo on the other hand find it useful to keep linked wallets, and pay Later pages due to the high recurrence of users coming to use the app more than once every week.

------------------------------------------------------------------------------------------------------------------

Now, here's a wireframe of a functional workflow for Retail Merchants to process E-commerce orders from HighStreet or Mall Stores, as opposed to Warehouse Models that traditional E-commerce firms operate on.

Next up, in order to provide Hyperlocal experience to offer same day delivery, it is not possible to utilise the traditional address field that most e-commerce platforms provide.

Here, data unavailability was the problem since ince majority hyperlocal partners work on lat-long as their prime source of logistics destination estimation (due to high number of deliveries being made by bikers, than delivery trucks and vans) we were required to provide accurate lat-longs of pickup and dropping points.

Hence we made changes to the address page to auto-fill details from Google Maps API by requesting user location access, and reverse geocoding the location to Lat-Longs and actual understandable addresses. 

Once need not fill fields such as Address 1, Address 2, Pincode, City etc, and undergoes a much more hassle-free ordering experience.